home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0026-More TDocument Disc-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  5.9 KB  |  109 lines  |  [TEXT/GEOL]
  1. Item    2683063                         8-June-89        06:44
  2.  
  3. From:   D0616                           Harold Feinleib Assoc, PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. cc:     X0501                           MacApp Developers Assoc, C Nelson
  8.  
  9. Sub:    More TDocument Discussion
  10.  
  11. Our TDocument problems:
  12.  
  13. We have had a similar problem with TDocuments, similar to the Accounting
  14. Package example being discussed.
  15.  
  16.     Our application, has the concept of a ‘Project’ (analogous to the ‘Company
  17. Set of Books’ in the Acctng pkg) which contain ‘Drawings’ (analogous to
  18. individual windows (reports, charts, etc.).
  19.     Our User Interface solution is to have a ‘Project Document’, of which only
  20. one is open at one time, and a number of ‘Drawing Documents’ belonging to that
  21. project. In the File Menu we have commands; New Project, Open & Close Project,
  22. a dashed line followed by a Save Command, Print… etc. We then have a Drawings
  23. Menu which has New Drawing, Close Drawing, and a list of Drawings belonging to
  24. that project. The “Save” is only highlighted if the top drawing has changes and
  25. Print, etc. actually apply to Drawings. The user never explicitly saves a
  26. project—it is saved automatically for him.
  27.     Users do not seem to have any difficulty with this concept.
  28.  
  29.     Our MacApp (1.1.1—sorry) implementation is to have the target chain of
  30. TOurApplication-TProjectDocument-TDrawingDocument-TWindow-TFrame-TView.
  31.     TOurApplication has its DoSetUpMenus & DoMenuCommand highlight & handle the
  32. New/Open Project MenuItems.
  33.     TProjectDocument maintains a list of TDrawingDocuments (fDrawingList). Its
  34. DoSetUpMenus & DoMenuCommand handles Close Project, specific project level
  35. commands, and all the items in the Drawings menus, except for Close Drawing.
  36. Closing the the Project does an fDrawingList.Each(CloseDrawing). The Project
  37. Document has no TWindows or Views and so does not get closed by closing any
  38. windows.
  39.     TDrawingDocument handles Close Drawing, Save, Print, etc. as well as all
  40. the specific commands that work on a drawing.
  41.  
  42.     In fact, our situation is much more complicated than that. Above the active
  43. window may be an additional special non-modal Dialog or Window that pertains to
  44. a particular TCommand which is active & is attached to the drawing window. And,
  45. it may have Dialog(s) associated with it. Thus our target chain really reads:
  46. TOurApplication-TProjectDocument-TDrawingDocument-TDrawingWindow-TDrawingFrame-
  47. TDrawingView-TNonModalDialogWindow-TNonModalDialogFrame-TNonModalDialogView-TMo
  48. dalDialogView…………….
  49.      Above all this, we have a floating toolbox window (with its own TWindow &
  50. TView) that sits above all these other windows and does not even appear in the
  51. target chain at all.
  52.  
  53.     The problem we have is not so much with the TDocument paradigm, which may
  54. be easily adapted, but with the target chain implementation. The problem is the
  55. Target Chain implementation is not a Chain at all. Much of MacApp depends (and
  56. I don’t know how true this still is in 2.0) on the target chain having the
  57. specific layout TApplication-TDocument-TWindow-TView.
  58.     For example, when a TDocument closes, instead of just unchaining itself it
  59. assumes that the target chain should just contain TApplication and so its sets
  60. gTarget := gApplication. There are numerous other places where this kind of
  61. behavior takes place.
  62.     The problems associated with overriding the TDocument DoSetUpMenus &
  63. DoMenuCommands to get nice behavior pale compared to several man-months needed
  64. to get the target chain to behave ‘nicely’. Target chain bugs still pop up with
  65. this project in its 2nd year of development. Because of these problems, going
  66. to 2.0 looms as a future nightmare.
  67.  
  68.     My year old suggestions as well as some new ones are:
  69.  
  70.     1) The Target chain should ideally be foreward and backward chained. It
  71. would probably be too difficult to change to this now.
  72.     2) TEvtHandler objects should, in general, search to the end of the chain
  73. and INSERT themselves when going on the chain.  They should DELETE themselves
  74. from the chain by searching for themselves rather than say, setting “gTarget :=
  75. fTarget” which assumes the target is in a certain format.
  76.     3) TEvtHandler objects might also have a flag(s) pertaining to their
  77. dealing with the target chain, i.e. an indicator that this object should not go
  78. on the target chain and/or one that indicates it should never be removed.
  79.     4) It should be allowable to have multiple TDocuments, Windows, View in the
  80. target chain at once. Perhaps Activate should be a method of TEvtHandlers. The
  81. method should call fNextHandler.Activate before/after deactivating/activating
  82. itself.  This requires more thought so when reactivating the path, the proper
  83. objects need to be activated.
  84.  
  85.     5) TDocuments should not required an overriding DoMakeViews (&
  86. DoMakeWindows) method.
  87.  
  88.     6) I agree with the TFile idea, recently discussed. A TFile object, a
  89. descendent of TObject, should correspond to a Physical Disk File. TBtreeFile
  90. could be a descendent of TFile as could TDatabaseFile(?).  It would be able to
  91. open, close, read and write itself.  These would be nicer objects than
  92. TDocument objects for when one needs to access other files in an application
  93. such as a Settings, or Dictionary file…. (Live Cut & Paste also needs to be
  94. considered.)
  95.     A TDocument would then have a TFileList which could contain zero or more
  96. TFile objects—default one. It would be more analogous to the ‘TModel’ idea
  97. brought up. Its Open, Close, DoRead & DoWrite methods could pass their calls to
  98. the TFile objects it owns.
  99.     I think this could be added to MacApp in a way transparent to current
  100. applications.
  101.  
  102.     An additional thought: I think users can understand a strictly hierarchical
  103. structure fairly easily. More complicated structures become incomprehensible.
  104. The exception to this may be Settings or Dictionary/Library files or files
  105. hidden from the users view and don’t require action on his part.
  106.  
  107.                                 Nick Pisarro, Jr.
  108.  
  109.